Codecov Report

Base: 0.00% // Head: 0.00% // No change to project coverage 👍

Coverage data is based on head (62c1bf1) compared to base (f733e6f).
Patch has no changes to coverable lines.

@@             Coverage Diff              @@
##           branch-23.02   #1177   +/-   ##
============================================
  Coverage          0.00%   0.00%           
============================================
  Files                 6       6           
  Lines               421     421           
============================================
  Misses              421     421           

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@bdice gentle ping on this. Anything I can do to help move this forward?

gentle ping on this. Anything I can do to help move this forward?

@kkraus14, for awareness, Bradley is OoO until 1/17.

This is on my radar. I’ve been working on other CI migration and platform support issues since the holidays but will return to it as soon as I can.

Just want to make sure this doesn't slip to 23.04 as this is a growing blocker as the conda-forge pinnings are at spdlog 1.11.0 and fmt 9, which means all new packages that rely on either of these libraries at runtime won't be able to be used in an environment with RAPIDS libraries.

I'm happy to help drive this to completion if I can help in any way.

@kkraus14 Thanks, I didn’t fully recognize the severity. I’ll prioritize this first thing tomorrow.

@kkraus14 Thanks, I didn’t fully recognize the severity. I’ll prioritize this first thing tomorrow.

To help keep conda and non conda builds in sync I have opened a rapids-cmake PR ( rapidsai/rapids-cmake#342 ) to update the spdlog version when not using conda.

@kkraus14 This is ready for additional review. I'll run some tests with downstream packages to ensure cuml and others can build with these changes.

(edit: looks like you approved as I was writing this comment!)

@kkraus14 I’m leaning towards bringing in fmt explicitly in rapids-cmake. The different bundling approaches in conda packages and CPM fetches are not ideal. Thoughts @robertmaynard?

Opened a PR (rapidsai/rapids-cmake#364) regardless of the short term decision here. My plan is once that lands then RMM can be moved to using fmt explicitly instead of via the spdlog headers.

One thing that I'm not clear on is that the spdlog conda packages currently use the SPDLOG_FMT_EXTERNAL option of spdlog (https://github.com/gabime/spdlog/blob/v1.x/CMakeLists.txt#L88) which uses an external fmt library via the fmt::fmt target. There's also an option of SPDLOG_FMT_EXTERNAL_HO (https://github.com/gabime/spdlog/blob/v1.x/CMakeLists.txt#L89) which then uses a header only fmt via the fmt::fmt-header-only target. I presume the SPDLOG_FMT_EXTERNAL_HO option makes more sense for us in the context where we're fetching spdlog as opposed to finding it?

@kkraus14 Yes, that sounds fine: conda packages can use the fmt library (dependency of spdlog) and CPM fetches of spdlog can rely on a header-only fmt that is also fetched by rapids-cmake.

@kkraus14 Yes, that sounds fine: conda packages can use the fmt library (dependency of spdlog) and CPM fetches of spdlog can rely on a header-only fmt that is also fetched by rapids-cmake.

Great, I'll tackle that in a follow up PR to rapidsai/rapids-cmake#364 once we bump the spdlog version to 1.11.0 since we'll need to change the rapids_cpm_spdlog logic a bit to find/fetch fmt first.

Next rapids-cmake PR that bumps spdlog to 1.11.0 and handles the fmt dependency is here: rapidsai/rapids-cmake#368

@bdice the rapids-cmake PR should be good to go where this PR should probably be updated to use fmt explicitly instead of indirectly via spdlog. I'm happy to make these changes if you'd like, but I'd need you to give me the ability to write to your branch (since it seems I'm no longer considered a maintainer of this repo which is a bit disappointing but a separate issue to be discussed).